With the advancement of the computer industry, the use of so-called integrated circuit cards or smartcards has become a preferred method of performing transactions on networks in many countries. For example such cards can be used as payment cards and this simplifies the purchase of goods and/or services by avoiding the necessity of using cash for such transactions while improving security compared to magstripe cards. These payment cards are often used in conjunction with electronic payment card or card accepting terminals (generally referred to herein as card reading terminals, point of sale terminals, or card readers).
Credit cards and debit cards are known. In recent years, an electronic wallet system has been suggested in which a monetary amount can be exchanged by communication between integrated circuit (“IC”) cards or between an IC card and a point of sale (“POS”) terminal. The IC card used for this system includes a microprocessor having a communication function and a memory such as electrically erasable programmable read-only memory (“EEPROM”) for storing a processing program, such as the MONDEX™ electronic cash application developed by Mondex International, Ltd. The processing program is capable of configuring the IC card to function as a credit card, a debit card or an electronic cash card.
If configured to function as a cash card, the IC card can be used for offline commercial transactions of merchandises, commodities and the like, and to allow information or data representing a monetary amount to be stored in a memory incorporated in the IC card. When the IC card runs out of electronic cash, the cardholder must deposit additional cash onto the IC card using a specialized terminal.
A typical message flow is as follows:                1) The terminal selects the application to use for the transaction (e.g. credit application) e.g. after selection by the cardholder.        2) The application (e.g. credit) is activated. The application prepares a message for the Issuer. The terminal forwards this message to the Issuer.        3) Based on the received message, the Issuer prepares the response (i.e. accept or not the transaction) and, possibly, a script command to be processed by the active application. The Issuer can only prepare the response and the script command after receiving the request from application. The command is delivered by the terminal to the card.        4) The transaction is approved or declined and the script command is processed by the active application (credit).It is inconvenient for consumers to carry multiple cards to conduct multiple types of transactions (such as one card for use as a debit card, and another card for use as a credit card). As a result, cards have been offered that allow a plurality of applications on one card. These cards are referred to herein as “combicards,” “combo cards” or “multi-application cards”.        
In a typical transaction involving the purchase of an item or service, the payment device (such as the combo card or combicard) is presented at a point of sale terminal (“POS terminal”). The POS terminal has a card reader that can read data stored on the payment device. Dependent on whether the payment device is configured as a cash, credit or debit card or a combination of these, relevant identifying information for each application is displayed in some way to the user for selection. For the card to be configured as a cash card, credit card, debit card or other type of device, the cardholder must have obtained prior approval from the card issuer to use the application(s) and as a result, every application on the payment device must be authorized.
A user may only wish to use an application for a short period of time. For example, a traveler visiting another country may wish to use an application that allows the traveler to conduct transactions in the currency of the country she will be visiting. This would require loading the new application onto the card. It is known to place more than one application on such a card but to make some of them dormant or “blocked” such that they cannot be used and cannot be seen at the POS terminal. Such a blocked application can be unblocked by presenting the card at a dedicated terminal (e.g. at a bank branch terminal equipped with special software). In this case, if the user wishes to make use of a new application, the card is introduced into the dedicated terminal, and the application running on the dedicated terminal selects the application to unblock on the card. The application on the card is then activated for use. The application on the card then prepares a message for the Issuer. The terminal forwards this message to the Issuer. Based on the received message, the Issuer prepares a script command to unblock the active application. The Issuer can only prepare the response (causing the application to be unblocked for use) after receiving the request from the blocked application. The command is delivered by the terminal to the card and the application is unblocked. This message flow requires that a blocked application can be activated while still in the blocked state. This is typically only allowed in a safe environment, e.g. using a dedicated terminal within a bank's premises.
This is somewhat more convenient than having to load the complete new application onto the card. However it still requires that the user take the card to the location of the dedicated terminal and interact with the dedicated terminal to activate the application.
A further difficulty is that existing payment network infrastructures impose limitations on how communications can be made with an IC card at a POS terminal. Only one application can be activated at one time for security reasons. The payment networks allow for only one request, from only one application. An online authorization (e.g., such as a request for a payment authorization) can only be performed with an application that is not blocked. The issuer needs a request from the blocked application to unblock it, but as it is blocked this cannot occur. As a result, currently, blocked applications cannot be unblocked at the POS terminal. This causes an inconvenience to the issuer. It would be preferred if new applications could be made available to the user in a more flexible and convenient manner.